 Great to be back in the States, coming in from Barcelona.
 I have jet lag, so I hope I don't fall asleep
 during the presentation.
 So those darn Sims, I'd like to explain the title a little bit.
 That's more than just a kind of catchy, 50s-ish phrase.
 It's actually an expansion of an acronym
 we used early on in the project, TDS,
 which we like to think in the design side
 as being the dollhouse simulator.
 But for the marketing people, it was also
 the tactical domestic simulator to make it less girlish.
 And there's my web address.
 And in lieu of handing out material now and wasting paper,
 I think I'm just going to post the presentation on my website,
 probably inside of next Tuesday.
 Next slide.
 Just a few questions for the audience.
 So a show of hands, how many have heard of the Sims
 before today?
 OK, just checking.
 How many have seen the game?
 Just about everyone.
 And played it?
 Almost everybody.
 And who has experience programming?
 OK, good.
 So this is a quick run-through of the game,
 in case there were some people that haven't seen it.
 First, this is the Create a Family screen.
 And you can make a family, like so.
 Add a member.
 Set the personality.
 And we have this ingenious little thing,
 so you don't have to click 40 times to make a personality.
 Call him King of the CGDC.
 Choose a nice programmerly body.
 Well, it doesn't matter.
 Biography.
 We don't have Lara Croft in here yet, so give her
 some personality.
 So that's Create a Family.
 And once you create a family, you move them into a house,
 like so.
 I have this blank one down here.
 So they start with a certain amount of money.
 And you have to use that money to build and furnish a house.
 I'm just going to do just a couple of basic things
 to show the house.
 There's some walls.
 And here's some wallpaper.
 The last talk I gave, there were only about 40 people out
 of what looked like seating for 500.
 So this is really great to see so many faces.
 So many people.
 So there's some walls and floors.
 And you have to watch your money total.
 Make sure you don't overdo it.
 So then once you build the house,
 you put it into Live Mode.
 This is Live Mode.
 So you can have them, you direct them to do things.
 And if you leave them alone, they'll do things on their own.
 The ongoing challenge of the game
 is to guide them through career tracks
 and maintain social relationships.
 This is a pre-release version of the game.
 So I can actually go over here and click and change
 the remotes, turn his fun down, so he
 can watch his fun going up as he watches TV.
 So that being shown, everyone knows pretty much
 how the game works.
 Move into a little bit about the data model that it uses.
 So we have type data, these things
 that all objects share.
 First thing on that list is graphics.
 These are 3D rendered sprites for all the states of an object.
 An example of the state you see there,
 the fridge is on the left is closed, on the right is open.
 Those are example of two graphical states.
 And it also has a composition list
 to reuse the sprite data.
 So for example, the back of the fridge is one sprite.
 And then as the state is parsed, the doors
 are added on in the open or closed state.
 The text includes various things.
 You can imagine the name and description
 for the catalog, menu items, and dialogue text.
 The animations and suits are programmed
 with Vitaboy technology using 3D skeletal animations.
 And they're applied to sims that are running interactions
 with the object.
 So for example, if someone gets something out of the fridge
 and they reach to it, that's an animation.
 Interactions, those are the entry point data
 for sims to interact with objects.
 So when you click on an object and choose something
 from the menu, it's parsing this interaction data
 to figure out, for example, if the interaction is available
 and how much the interaction can change the happiness,
 things like that.
 And then simulation data, this is actually
 code in an embedded language, which I'll
 talk about extensively later.
 And it drives the object's main simulation, which
 for example, controls how often an appliance might break down
 or things like that.
 It also controls the sim's interaction with the objects
 and some kind of user placement restrictions.
 For example, if it has to be against a wall
 or if it's an invisible object that sits outside the world
 and just kind of controls things and does simulation effects.
 And then lastly, properties, which
 contain things that aren't already contained
 in the simulation data, particularly
 things that need to be parsed before the object is ever
 created, such as the globally unique identifier.
 And on the right, we have the instance data, location,
 rotation, pretty obvious, the current graphic,
 repair state and cleanliness, just a couple
 of examples of global data.
 So these are used on a global level
 to do things like compute the room score.
 So if there's a lot of dirty objects in a room,
 the game gives that room a negative score
 and the sims in that room are less happy.
 And then we have object defined variables.
 So typically, things like on or off for appliances
 or remaining life, the time that it has left
 before it's going to break down.
 And then relationships to other objects.
 So an object can actually define an arbitrary number
 of variables in relation to other objects.
 So they can do things like tagging an object
 or maintaining some kind of external data relating
 to a different object.
 That's about it for the objects.
 Then people are actually types of objects.
 They inherit everything I talked about on the last slide.
 And they also get these new things,
 which are kind of type data, kind of instance data.
 It's kind of a fuzzy line because there's typically
 only one instance of each type of person.
 So the people I made, the king of the CGDC, he's a type.
 And he's also an instance.
 He's both.
 So we have their appearance and age, which
 is selected by the user.
 Family, which is also selected by the user.
 House, the animation and routing state,
 so the instantaneous point of having a leg forward
 or the sequence of points that the person
 is traversing at the moment.
 And we have the interaction queue,
 which I don't think this was entirely clear before.
 But if I tell him to do several things,
 then they show up in the top right.
 And those are things in his interaction queue.
 And the graphical queue there is pretty much
 an exact reflection of what's being stored in the game.
 And then simulation data is what I'm here
 to talk about, more or less.
 We have the motives.
 These are the things that drive the sim
 to behave the way they do.
 We have physical motives, bladder, hunger, hygiene,
 comfort.
 And mental motives, energy, fun.
 Social and room motive, which is also
 like an environment motive.
 So if that motive is low, they might
 do something like clean the floor,
 touch up things in the room.
 And I'll talk more about motives later.
 And personality, these are the things
 that the user selects when they create a character.
 These don't change.
 So a sloppy person will always be sloppy.
 They can't learn.
 So those are those.
 I'll talk a little bit about those, not too much.
 Skills, we have mechanical, cooking, creativity, physical,
 charisma, and logic.
 And these serve basically two purposes.
 One, to control how fast the sim does certain interactions,
 like repairing, or cooking, or painting.
 So it's kind of an efficiency rating.
 And then relationships, these are actually
 the same as in the objects.
 However, with people, there's a special interpretation,
 which is the level of friendliness between two sims.
 So I just have a couple of names there.
 Mortimer, 58, that's a friend.
 Bella, 93, which is a, you can also
 have a tag in the relationship, whether or not
 they're in love, which enables certain interactions.
 I'll let you imagine what those are.
 And then Bob there, doesn't like Bob very much at all.
 They're not friends.
 So that being done, we have the object in person data model.
 Everything is plug-in based.
 It's done through what we call resource files.
 So all of the data we just talked about
 is generally stored in a file with the object.
 So we have behavior, interactions, and entry points,
 which I already talked about a little bit.
 And internal, and these are functions
 in the embedded language, which are just
 used internally and called by the simulations of the objects.
 And then the graphics, talked about the sprites
 a little bit already.
 The catalog graphic is also stored in the resource file.
 And then any additional graphics that
 might be needed for dialogues.
 Texts, also talked about a little bit.
 Animations, these are just a list
 of names that refer to Vitaboy trademark CMX files,
 subject of another CGDC talk in itself, I'm sure.
 And then the properties, the object definition,
 talk about that on the next slide too.
 And then the sounds are like the animations,
 they're a list of names of scripts
 and a sound scripting system, which could also
 be another CGDC talk, I think.
 So just a little bit about definitions.
 Definition is an object resource type, so it lives in the file.
 And each definition resource determines a new type of object.
 And multiple types may reside in the same file
 so that they can share resources.
 And this is just a really simple picture of how the chairs are
 all in the same file.
 And they reference the same behaviors, same everything
 pretty much except for the graphics.
 So they have a different look, but they all
 share the same code and everything.
 And just a quick word to multi-tile objects.
 Any object that occupies more than one tile
 is split off into separate objects.
 Each piece is its own object.
 And the guiding piece, the master piece,
 is used to store common data.
 And then the relative locations of the other pieces
 are stored in the definition so that they
 can be composed when the user places or rotates the object.
 And a word about the simulation.
 Frequently in multi-tile objects,
 one object is the smart piece and has
 a non-trivial simulation, and the other one's just
 sleep the whole time.
 And this is just a little bit about how
 the objects are loaded.
 When the game starts up, it searches a set of directories,
 the primary one here being game data objects.
 And then each file it finds in there
 that's an object resource file.
 Essentially, if it ends in .iff, which
 is the extension we chose.
 And then it just looks for definitions within those files.
 And each one it finds, it makes a new type
 that's shown in the catalog.
 So we show here that the three lamps live in the same file,
 whereas the aquarium just has one object.
 Just up to the programmer.
 So now, we talked about plugins, so move
 on to the overall simulation.
 This is just a simple loop, basically.
 What you see here is a graphical representation of it.
 And it's executed over and over until the user decides to quit.
 So each iteration of the loop advances the state machine
 of each object instance by a single transition
 and represents a single unit of time called a tick.
 So it's completely asynchronous.
 Every object just runs until it's
 gotten to its next yielding state.
 And then control is passed to the next object.
 So everything is on the same clock.
 So semantics is basically the core of the simulation
 in the sense it's an embedded language called semantics.
 It allows objects to be driven by programs
 outside the C++ code.
 So in the picture here, that's kind
 of the same thing from the last slide.
 The main simulator calls upon the object instances
 to simulate themselves.
 And they, in turn, call the semantics interpreter,
 which loads the current instruction
 from the semantics functions binary data.
 Those live in the object resource file, like I said.
 And they parse the binary data into calls to C++ functions
 called primitives.
 And those are the building blocks of the language.
 Each primitive has a specific task that it does.
 And then to provide a little context for that information,
 there's also other simulation resources
 within the object type.
 And the yellow arrows show data access.
 So we see that semantics primitives
 can access data from the main simulator,
 such as the time of day, other things,
 the current house that's being played, and things like that.
 And access data in the object instance,
 like the routing state.
 So if a primitive is going to route a person,
 it can push some destinations onto the stack of the route.
 And lastly, we have the editing, the type data.
 So on the right-hand side, you see Edith there,
 which is our main editor.
 And that's an in-game tool, which allows the programmer
 to edit the functions graphically.
 And what you see on the top there
 is one of our most important editors, the tree editor,
 which allows the scripts to be edited.
 They're called trees because they
 look a little bit like trees, and branches, and roots.
 And there's also a bunch of other editors,
 such as interaction editor.
 You can add new animations and sounds from Edith as well.
 And then lastly, we have other tools
 that import data from things like a database,
 or for the graphics, 3D Studio Max.
 So now we're moving on to the tree editor.
 I have a simple function shown here.
 So like I said, the tree editor shows the functions graphically.
 Each instruction or primitive is a box,
 and then each arrow shows the flow of control.
 So if a box has a true return value,
 then the true arrow is followed.
 And that's going to be the next state at the end of the arrow.
 So this is just a simple function.
 I'll explain.
 The first thing there is a subroutine call,
 go to adjacent tile.
 So if that returns true, the sim should
 be next to the lamp within one tile.
 And then we have some kind of bulletproofing there.
 Make sure they're not turning on a broken lamp.
 And then the animation is run, and it exits.
 So very simple.
 It's all made from the primitives.
 And then to show one more complicated,
 switch over to Edith.
 This is a pre-release version of the game with Edith,
 so I can do this.
 Of course, in the real game, there's
 no way to know that this exists.
 So I bring up the object editor for the baby,
 and look at the main routine for the baby.
 It's a good bit more complicated.
 So I'm just kind of scrolling through this.
 So the first thing it does is it calls everyone over,
 makes it like a party.
 All the sims come over and clap and cry, everything.
 Then do appear, that's basically an animation
 that shows the carriage or the baby cradle appearing,
 since we don't have any doctors to give birth
 to children in the game.
 We have some other primitives here.
 Here's an example of a way that parameters are edited.
 This is a user event primitive.
 So this calls and hooks into the graphical engine and says,
 show this event to the user in a special way,
 and put a photo in the scrapbook, things like that.
 We have some dialogue primitives here.
 Choose a random number for the gender.
 Congratulations, it's a boy.
 And this one, of course, congratulations, it's a girl.
 Then it does some more setup, and then it
 goes into its waiting loop.
 And it waits to see if the user is
 taking good care of the baby.
 So that's a pretty complicated main loop,
 one of the more complicated ones in the game.
 Now we have starting the section on interactions.
 So here, when the user clicks on an object,
 it shows a list of interactions that the currently selected
 sim can do with that object.
 Objects enumerate this data from their file,
 like I was saying before.
 So each of these interactions is a semantics function
 that is actually pushed onto the stack of the sim that
 runs the function.
 And furthermore, they include a function
 to test the availability so that the object has
 a chance to disable the interaction if it's not
 available.
 For example, if the stereo were off now,
 instead of turn off, you would see turn on.
 And none of the switch to next station or switching stations
 would not be enabled.
 So everything hooks into semantics
 for the interactions.
 Here's a flowchart of how that menu is generated.
 It actually probably looks more complicated than it is.
 The most interesting thing there is
 that it generates an invisible destination object when
 there's no object underneath where the user clicks.
 So for example, I click here.
 It generates an invisible object there
 which just has a go here, and so it lets the person walk.
 And then if there's an object with no interactions
 available, such as this one, we get a message, no interactions.
 So back to the flowchart.
 So once it has the object, it generates that interaction list
 by testing the availability of each one,
 and finally building the menu.
 And if there was a user selection,
 it pushes it onto the queue.
 So it's just a word about interactions.
 And then object simulation.
 The objects are simulated completely within semantics.
 There's no additional code necessary to simulate
 the objects.
 Once an object has been created and placed,
 the main simulation started up.
 And here's an example of a simple main simulation.
 And first it just does a delay, and then later on it
 does a test to see whether it should burn out or not,
 burn out the bulb.
 And if it should burn out, it calls
 a function that will transition into a burnt out state.
 And actually, I think I did the other demo at the wrong time.
 The main simulation of the baby was supposed to go here.
 But you've already seen that, so I think it's OK.
 So these are the motives of another additional part
 of the person simulation.
 So that was the object simulation.
 Now the person simulation is a little bit different.
 It uses semantics, but also has code
 that runs all the time regardless of semantics.
 And one of those is the motive engine.
 This was designed by Will Wright in the early stages
 of the development of the game.
 And it's pretty much stayed unchanged.
 These emulate the motives of real humans.
 And these are just a few examples of the motives.
 So energy doing the sleep cycle.
 Basically, the rates are chosen so that after about 16 hours,
 a fully refreshed person will be tired.
 And then after about eight hours of sleeping,
 they'll be back and ready, recharged.
 The hunger motive, three meals per day,
 starvation after five days.
 It's actually asymptotic to the minimum.
 So eventually, it reaches a point to where they're dead
 and they die.
 The social motive, that decreases more rapidly
 for outgoing sims.
 So the effect of that is that outgoing sims will need
 to talk to people more often.
 That's a pretty good effect.
 And then the room motive, that's a special one.
 It's computed from architecture.
 Talked about that for a second before.
 How the dirty objects can affect a sim negatively.
 And then we have another thing that's done internally
 in the game is the mood.
 So the instantaneous happiness of the sim, that's the mood.
 And it's computed from the values of the other motives.
 And the formula there is the sum over all the motives
 of the value of the motive times the weight curve
 of the motive at its current value
 over the sum of the weights.
 And those are the weights.
 As you can see, the physical ones
 tend to go really high in the negative regions.
 And so that has the effect of really over-weighting those,
 just to demonstrate that quickly in the game.
 So we have, even though his motives here
 are pretty much super high except for hunger,
 his happiness is very middling.
 It's right around zero.
 So that's an example of how the weights work.
 Next thing we have is just the main loop of the person.
 So this is actually a semantics function.
 And I just put it in a flow chart
 so I could eliminate a lot of the bulletproofing
 and stuff that's not necessary.
 So the first thing they do is motive failure and feedback.
 Actually, I think we may have just seen a feedback there.
 That little thopolin that he's wearing
 is a feedback saying he's hungry.
 So at that point in the main loop of the person,
 they check their motives and decide whether or not
 they're gonna give any feedback.
 And failure, actually, the main loop is responsible
 for killing the sim if one of the motives is too low.
 Or making them create a puddle on the floor
 if, for example, their bladder motive is too low.
 So after that, it goes into testing
 to see if an interaction is in the queue.
 So if the user clicked and made an interaction
 for the sim to do.
 If so, the action is pushed onto the stack
 and then the object behavior code is allowed to finish
 until it returns and goes back to the top of the loop.
 However, if the user did not click,
 they go into their autonomous mode
 and do the find best action.
 That's just the name of the primitive
 that does the autonomous search.
 And that'll be talked about more later.
 And then just to give the context here,
 that's basically the autonomy on the left
 and the user control on the right.
 And they just alternate between the two,
 giving preference to user control.
 So, find best action.
 Semantics primitive, as I just said,
 implements the autonomous selection of the sims.
 It's called by the sims when idle,
 like we saw on the flow chart.
 And the free will option's on, of course.
 That's, if you played the game,
 you've probably seen the checkbox
 that has whether or not the sims
 are supposed to be autonomous or not.
 So, the main thing it does is it scans
 all the interactions in the world.
 So for each object, it loops through,
 all the objects loops through all the interactions
 in each object.
 And then it allows the semantics code
 to adjust the advertisements.
 I'll talk more about what the advertisements are,
 but those are basically,
 well, they're like advertisements.
 But they tell the people, they tell the sim
 what they could possibly gain from doing the interaction.
 So, for example, social interaction
 would have an advertisement on the social motive,
 saying come talk to this person and you'll get happy.
 Then it also does a further adjustment of the advertisements
 based on instance variables,
 including the current motives through response curves,
 which I'll talk about in a couple of slides.
 And the personality.
 So, sims may be more likely to do something
 if they're more playful or less playful
 or more sloppy, less sloppy.
 Finally, it generates a score
 from the adjusted advertisements.
 And then attenuates the score by the distance
 and chooses the best interaction out of all scanned.
 So this is the basic autonomous behavior.
 And now we'll talk about the scoring.
 As an example, I chose two objects,
 both of the same advertisement.
 One of them is for playing and one is for eating.
 We call those motive channels.
 It's kind of like going with the advertisement analogy.
 So fun plus 25, hunger plus 25.
 Pretty simple.
 Play or eat.
 He doesn't know what to do.
 But his hunger is less than his fun.
 His fun is pretty low, but his hunger is lower.
 So what happens is the score ends up being less
 for the pinball machine because it's adjusted
 to take into account the current motives.
 And he will go ahead and eat in that situation.
 And this segment allows the semantics code
 to modify the advertisements.
 So I was talking a little bit before
 about how there's a semantics function
 to test the availability of an interaction.
 Well, there's also, they have the opportunity
 to operate on a copy of the advertisements.
 And then the modified copy is used
 in the score computation.
 So it allows an effect such as user training,
 which I've outlined a little bit here.
 The three components would be during the interaction,
 that is each time that the sim goes
 to interact with the object,
 one of the object state variables is incremented,
 the prior use count.
 And then in the main function,
 it's decremented at a certain rate.
 The most notable object this was used for is the bed.
 So that idle time period would be one day
 since people generally sleep once a day.
 And after one day, it's decremented by one.
 And then in the test function,
 the add is incremented.
 For the case of the beds, this would be the energy add.
 Is incremented by that prior use count times a constant.
 And this basically makes it so that
 if the user clicks on one bed enough times
 and tells the person to sleep there,
 that in the end they'll choose that bed by themselves.
 And now we have personality.
 So the primitive also modifies the advertisement
 based on the personality.
 So we have here two objects,
 both advertising on the fun channel, equal advertisements.
 He can play or read.
 And we see his personality, he's not so playful.
 So we think intuitively he may not enjoy
 the pinball machine as much as reading.
 And so the primitive uses the more interaction data
 stored with the objects to diminish these advertisements
 based on personality.
 He's not so playful, so he ends up going to read.
 So now backtracking a little bit to the mode of response.
 This is the way the scores are generated.
 So we have a set of advertisements,
 eight total or nine total.
 And then all the values for those advertisements
 are passed through response curves,
 which are R sub M in this formula.
 And then all the response curves will pop up here.
 And so the current mode of value
 determines a point on these graphs
 from minus 100 to 100.
 And the slope of the graph at that point
 determines the response,
 as we're multiplying by the derivative.
 So in the flat region, for example,
 there won't be any response.
 So you can see from this, for example, energy,
 the Sims won't autonomously respond to energy
 until a fairly low point,
 which is about right.
 Otherwise, people would sleep all day.
 So these curves control the overall intelligence
 of the Sims.
 So we had the motive engine that I talked about before
 that controls the overall feel of the Sims.
 This is the overall intelligence.
 So it keeps them from being too smart or too dumb.
 So for example, if all these curves were completely flat,
 the Sims would never engage in any autonomous interactions.
 Or if they were all a straight line,
 then they would theoretically maintain their motives
 at the highest point,
 not giving the user anything to do.
 And just as a side note,
 these are all stored in a global resource file
 so they can be changed.
 And here we have the Happyscape.
 It's one of the better slides.
 This is the final stage of what the primitive does.
 It's a distance attenuation.
 So the resulting graph may be thought of as a landscape
 in which the Sims traverse the region of least resistance.
 So right now, where that Sim is,
 it's on the light green.
 She's on the light green.
 So she'll probably go to that object
 represented by the light green hill.
 So the hills are interactions.
 Each one has its own decay rate and everything.
 The peak is the location of the object.
 And the height is the raw score
 before the distance attenuation.
 And the slope is the attenuation factor.
 You see the red is very steep.
 That's a high attenuation factor.
 Medium, low.
 And then an object can also say no attenuation factor,
 which is useful for things like the beds.
 You don't want them to sleep on the couch
 just because they're a little bit too far away
 from their bed.
 And I have a demo relating to this.
 Just wait for this house to load.
 So what we see here is kind of a graph of the happy scape.
 And depending on his motives,
 different things will be on top of the hill.
 So I'd make the bladder motive the lowest one.
 We see the two toilets there
 with a line right down the middle,
 which is what you would expect.
 Turn the hygiene down.
 You should see the shower on top of the hill
 and the bathtub.
 Turn a lot of them down.
 You should see several peaks.
 Probably the hunger will end up being the highest.
 You see the barbecue is high here.
 Sometimes objects are disabled,
 so this doesn't always accurately reflect
 the state of the world.
 Uh-oh.
 Sorry about that.
 It never crashed when I was rehearsing.
 Okay.
 Well, you get the idea.
 I'll maybe show that demo again
 if there's any questions on it.
 So this is the actual formula.
 So I took the formula and plugged it
 into a 3D graphing calculator
 and just had to adjust the coefficients a little bit.
 That's pretty much what it looks like.
 The raw score divided by the sum of one
 plus a factor times the distance.
 Whoa.
 There's a bug in PowerPoint.
 Well, you can see here.
 But it's not animated.
 These are, can you read that?
 Let's see if this works.
 Well, probably I need a reboot.
 But I'll spare you and just make this larger.
 So these are just a couple of interpretations of the graph.
 The cross-section would be just the interaction
 sorted by score.
 So depending on the location of the sim,
 the highest graph at the point where the sim is
 would be the best interaction.
 And you can see how that changes over time
 depending on the different attenuation rates
 and the different hills that are in the world.
 And then we have the overhead view on the right there,
 which are the zones of selection.
 So if a sim is standing in the red zone,
 they'll choose interaction,
 so if a sim is standing in the red zone,
 they'll choose interaction A,
 or the yellow zone, B, and so forth.
 And I must have been really nervous
 because I finished this super fast.
 It was actually closer to an hour
 when I rehearsed it last time.
 So that's the last slide.
 Any questions?
 This editor, Edith, I assume that's just used
 in Java again?
 Yeah, that's right.
 He asked if Edith was just used internally.
 Yeah, he's asking if we'd ever thought
 about making Edith available to the general public.
 And yes, we have.
 But it's not really up to me anymore.
 I'm not at the company.
 I'm just here as a representative.
 But no, we're probably not gonna make it public at this time.
 I'm in favor of it, personally.
 I have a question.
 Whether that's for business or technical reasons,
 or is it more because there's a certain technical reason
 for the public to use it?
 He's asked now if it's more for technical reasons
 or for business reasons that the editor
 was not made available to the public.
 And it's largely, largely business reasons.
 It's not in our interest to have problems
 with versions of objects created by who knows,
 and possibly getting blamed or getting stuck
 with the responsibility of maintaining compatibility
 with who knows what people are doing.
 But technically, it's not that big of an issue.
 And actually, one of the demos I was gonna do
 is actually change an object to do something differently
 with the editor.
 It's not very hard.
 You can cheat and make an object
 that just keeps everyone's motives
 at full board the whole time.
 Yes, in the back.
 Is there a simpler version of this
 that was used in the early design stages
 to playtest the basic interactions of the game?
 An earlier version of what?
 The core logic of it.
 Was there a simpler prototype version
 that had some of the simpler tests
 done at the same time?
 So he's asking if there was a simpler prototype version
 during the development to test some of the interactions.
 And yes, there were quite a few prototypes.
 We had actually one program
 that was only the core motive simulation.
 So you just click on it
 until they have to go to the bathroom
 and see if it feels right.
 That was something that Will had worked on.
 And actually, it was originally on the Macintosh,
 and the graphics were really bad.
 We had a lot of really ugly things,
 programmer art and whatnot.
 But actually, most of it kind of came together
 towards the end of the project.
 So a lot of the prototypes really helped us,
 but then we did a lot of the tuning at the end
 that really made the game.
 In the front?
 Could you explain how it was tested
 and how you ensured the quality and nature of it?
 So he's asking a question about the quality assurance
 and how we tested it.
 Well, there was a lot of tweaking and tuning.
 So basically, everything is kind of based on a number.
 So how often does a TV break?
 How often does a person want to go to the bathroom,
 things like that, and is it fun?
 We did a lot of playtesting,
 so trying the game out with a set of tuning constants
 and getting feedback from the people that tested it.
 And a lot of it was also just kind of thinking to yourself,
 what would a person do in this situation?
 The game is about people, so to tune it,
 you do have this vast knowledge on your own part
 of how it feels to be a person.
 So it actually meant more from a technical point of view
 instead of an experience point of view.
 How did you make sure that there were no special cases
 where things went wrong?
 So he's asking a question now
 about the technical aspects of testing.
 Well, actually, the game can be put onto high speed,
 and with the autonomy on,
 they'll go through pretty much every interaction.
 So that's what we did a lot of the time,
 just leave them on all night at high speed,
 come back in the morning and see what had crashed.
 And we had a thing that would dump out a stack trace
 of the code itself, so even if it blue screened,
 we would possibly still have the information
 of where it crashed.
 Furthermore, well, beyond that,
 we did do a lot of kind of pounding on the object.
 So after someone would write an object script,
 we'd put just dozens of that object in the world
 and basically keep on tweaking the motive
 that makes them go to that object
 and just pound on it and put it with eight people,
 10 people, 20 people, and try to get them
 all interacting with the same object at the same time
 and make sure that there were no holes
 in the bulletproofing.
 So basically pounding.
 Next one, okay.
 Is there any randomness involved
 in when they make an autonomous decision, what they do?
 And if not, did you ever think about it?
 Ah, right, right, yes, there is, there is.
 I meant to say that.
 I'm sorry I didn't say that.
 So all I was talking about in the last few slides here
 were relating to how to find the best action.
 And what we actually ended up doing,
 they were still a little bit too smart.
 There wasn't enough, you know, they were too predictable.
 And it wasn't very fun.
 So it turns out that they're taking a random choice
 from the top four interactions that are found.
 So you end up, you know,
 they'll sometimes ignore a motive, apparently.
 And it's not because the game's not capable
 of finding that motive, it's just that we chose that
 so it'd be funner.
 There's a lot more failure cases because of that now.
 Back there, in the red jacket.
 Yeah, when will this get, after they move on,
 will they stand their ground?
 I mean, I'm not an expert, but I'd say
 it's gonna be a couple of years from now.
 It's pretty frustrating.
 I'm kind of late for work because of that.
 Why are you trying to make me do that?
 When you put a cancel on action and you start looking,
 they'll still be standing there.
 Right.
 Okay, she's asking why the long pauses in the routing.
 Yeah, if you've played the game,
 you notice if someone's trying to route to a certain point
 and they run into another person on the way,
 they'll have to recalculate the route,
 but they actually wait quite a long time.
 I think this is probably a bug,
 but it could be conflicting.
 It could be a conflict with another bug.
 So if we didn't have that,
 people could get stuck in doorways, for example.
 That was a big problem.
 People would cluster around doorways
 if there's a small room.
 So to ameliorate one problem, we have a solution
 which perhaps is more frustrating,
 but it seems to have made it through testing, so.
 Yeah.
 Over here on the left.
 There's a number of different factors in the room score.
 He's asking how the game computes the room score.
 A number of different factors.
 Like I had pointed out in the show here,
 the cleanliness of objects affects it.
 So a trash pile has a really low cleanliness.
 So that contributes negatively quite a bit.
 So there's that, and there's the size of the room.
 Takes into account the size of the room.
 The formulas for all of this,
 these are pretty complex and highly tuned
 to try to get a reasonable score
 for a really horrible room.
 The way we did it was,
 if you make a three by three room with no windows,
 that's about the lowest score you can get.
 Whereas if you make something like seven by seven room
 with about 30% of the tiles covered with windows,
 30% of the exterior tiles,
 that's about the highest score you can get
 with respect to lighting.
 And then the next thing is wallpaper and floor.
 If you don't bother putting wallpaper up for floor tiles,
 it's pretty low.
 And the last thing is a special score for outdoors.
 There's a computation involving
 just the number of objects you have outdoors.
 So if you have a nice garden,
 then those contribute positively.
 Whereas if you let the garden wilt, that's negative.
 Over here.
 Why did you develop your own scripting language
 and why is it a graphical language?
 He asked why we developed our own scripting language
 and why is it graphical.
 It's really early on that the scripting language
 was conceived.
 Will, I talked about before,
 Will Wright conceived of it together with me.
 We talked about a way of specifying human behavior
 in a really simple format.
 And we felt that the graphical implementation
 would help to keep it simple.
 Because you can't have programmers
 dragging around 4,000 boxes.
 So it did actually stay pretty simple.
 And we have it.
 So why did we develop our own scripting system?
 It seemed like a good idea.
 Hey, can you explain how a character chooses a surface?
 How a character chooses what?
 Surface.
 I don't know how a character can choose a surface.
 Which one is it on?
 Ah, surface.
 So for these graphs we're looking at right now?
 We can kind of see here in the cross-sectional view
 how some of the cones will fall down
 underneath other cones.
 The characters simply choose a random interaction
 from the top four graphs that they're standing on.
 And he just asked how a character makes the choice
 in this landscape.
 So for example, she's on the light green.
 If she were to walk a few steps into the screen,
 into the left, she might be on the yellow cone.
 And then theoretically,
 if we didn't have the randomness in there,
 she would choose the yellow one.
 Next, here?
 What's the development effort for the programming?
 How does that compare to the actual content
 and behavior of the game?
 Oh, you mean the development of the system to program
 compared to the actual programming of the objects?
 Yes.
 Okay, so he's asking about the development times
 and developing the system for making objects
 and then for actually making the objects.
 It's kind of hard to say.
 We went through so many prototypes,
 but basically I was working with the game experimentally.
 It wasn't slated as a real product.
 It wasn't on much of any schedule
 for about two and a half years.
 And then we brought in people to do the graphics,
 at which time the team was growing and growing and growing.
 So we had a core group that was doing simulation
 and graphics and the object editor and things like that.
 Yeah, it is hard to say.
 I think we probably spent about six months originally
 on the editor, and then it was added in bits and pieces,
 added onto in bits and pieces later and later.
 But the thing is, when you add a primitive,
 it's really usually a simple task.
 The primitives don't have to do that much,
 except for the routing
 and some of the more complex primitives.
 So a primitive is needed.
 The primitive is added within two days maybe.
 And then the objects can use that primitive far and wide
 throughout the whole game.
 And then object programming was probably
 about the last year of development.
 There was a full-time object programmer
 and then some other part-time ones.
 Right here.
 In the expansion pack, like Living Large,
 you have some objects that seem like they're really
 complicated, for example, like the chemistry set
 or the voodoo doll.
 And I'm wondering if there was a lot of programming
 happening to that, or was that just distributed?
 He's asking if in the expansion pack
 there was a lot of new programming
 for objects like the chemistry set or the voodoo doll.
 Actually, a good person to answer that would be Patrick
 Barrett, if he's here.
 Or Will.
 What do you have to say, Will?
 Will change the code development.
 Yeah.
 Yeah, he's verifying what I had heard before,
 but I wasn't sure that there was actually no code changes.
 Only Edith editing modifications, new objects.
 What does IFF stand for?
 Pardon?
 The IFF files for objects.
 Originally, it stood for Interchange File Format.
 Beaver.
 Beaver.
 Could be.
 Could be, actually.
 I got the idea from a guy that might be here.
 Jason Schenkel gave me the idea.
 And anyway, it's called that because the file
 can be read without knowing the specific format of the file.
 It can read a header for one thing and skip over it.
 And if it's interested, it can look at that.
 But the way it ended up working is not
 really exactly like that, but it's similar.
 Right here?
 So he's asking how we developed the,
 how we chose to design certain objects.
 The programmer's role in the design
 of the objects and the primitives.
 Well, in the case of the Sims 1.0,
 Will was designing the large part of the objects.
 And we had a couple of other designers
 that were also working on that.
 Will moved into more kind of overall gameplay tuning.
 And the specifics of the objects were
 left to the other designers.
 But there were quite a few arguments, actually,
 between the programmer and the designer
 because sometimes there would be a simple change requested
 on the part of the designers.
 A change that seemed simple.
 And the object programmer would say,
 I'm going to have to rewrite all these trees,
 dragging all these things around.
 So it's a bit of an imperfect system there.
 I mean, on the one hand, it's really extensible
 and you can do all this stuff graphically.
 But on the other hand, it's kind of a pain
 to click the mouse so many times instead of just changing
 one line of text or something.
 Up here?
 Was there any sort of inheritance or anything
 with the method that someone gave the topic
 that could take the other one and take a step?
 He's asking if there was any inheritance in the object
 model.
 So if an object could take on common characteristics,
 a group of objects could have a common base class.
 Not really.
 There was, but it wasn't very good.
 What we had was an intermediate level of behaviors.
 So it was called semi-global.
 So we had global, private, and then in between.
 And it turned out it wasn't that useful.
 There wasn't a good inheritance model.
 So what we ended up doing, for the most part,
 is just putting all the objects that
 have the same behavior in the same file.
 So for example, the lamps I talked about earlier,
 they do that.
 And next guy, the one in the white shirt.
 Was there any consideration of giving these sim characters
 or the humans modeling their knowledge
 so that one character might know something
 and another one wouldn't?
 Because they all know everything that exists in the world.
 So he asked if there's any knowledge modeling
 to the effect that one sim might know something
 and another sim would not know something.
 And the short answer is no.
 It was thought about.
 But every sim knows everything in the world.
 Back here.
 How does this go on the actual thought bubbles
 and how those were populated by the sims themselves?
 Like, just the thought bubbles that the sims
 were actually going to generate?
 Ah, right, right.
 He's asking how we populated the thought bubbles that
 exist during conversations that the sims have.
 Actually, there's an invisible object.
 Every time a person goes to talk to another person,
 an invisible object is spawned that
 negotiates the conversation topics
 and tells one person to do, for example, the soccer balloon
 and the other person to say, I don't like soccer.
 And it's kind of a game in itself, that object.
 But basically, each person has a set
 of interests that are randomized as part of their state data.
 So a person can have interest in sports
 or interest in some of the other topics.
 I think one of them might be UFOs.
 I can't remember them all off the top of my head.
 So each person has interest.
 And the social object negotiates the back and forth
 of the conversation topics using the interest variables.
 Over here, in the blue shirt.
 Yeah.
 The choice of the response curves and emotives
 and everything that you ended up putting into the game,
 was there a particular behavioral or psychological
 model that you used for that?
 What was that commentary choice?
 So he's asking if we chose the motive model arbitrarily
 or if it's based on psychological evidence.
 That's a good question.
 I'm not really sure about that.
 I know in the beginning, we had about two dozen motives
 instead of just 10.
 I think that making it 10 was partially
 in the interest of the user and in the interest of keeping
 the game fun and not too much like some kind of spreadsheet,
 really complicated spreadsheet.
 In terms of the psychology, I don't
 know if Will would be interested in saying something
 about the psychology in his thinking on that.
 So what did you say it was based on, the one reference?
 Abraham Manslow?
 No, Naslow.
 Naslow.
 OK.
 So Abraham Naslow's model of needs.
 Back here, in the blue.
 I'm talking about social interactions.
 Do the Sims advertise benefits to all the Sims?
 Like energy or things like that?
 Yes, they do.
 Yeah, he's asking if the Sims advertise
 for the social interactions to other Sims.
 And yes, they do.
 If my demo hadn't crashed or PowerPoint hadn't crashed,
 whatever that was that crashed, I
 would have shown how the people will rise up on peaks.
 If I lower the social mode, you can
 see that the people come up on sharp peaks
 with a red circle around them in that demo, if you remember that.
 So a couple more questions.
 Just about out of time.
 Yeah?
 You're doing multiplayer now, right?
 Yes, the multiplayer is in the works at EA.
 I'm actually not at EA anymore.
 Do you know how much of this they'll save
 or whether they'll rewrite it from scratch?
 So he's asking how much of this will be saved for the multiplayer
 version.
 I honestly don't have any idea.
 When I left, actually, they were converting
 the code to be multiplayer.
 So it was completely using everything.
 And I think that the object system will stay intact.
 It's proven fairly powerful, the way
 that we released the expansion pack without changing the code.
 Pretty nice benefit.
 So I think that the object system, at least, will stay.
 Perhaps other things will be rewritten.
 Back, black shirt.
 What's the formula for success in the 18 to 25 female market?
 What's the formula for success in the 18 to 25 market?
 Female market.
 Female market.
 I would say less blood.
 Not my field.
 Tell me about the program.
 One more report.
 OK, front.
 You said that the sponsors were in a global,
 where you could access another domain.
 Is that accessible to users?
 And my other question was also, these visualizations
 you have, did you work with that when you were developing?
 OK.
 OK, last couple of questions.
 It was, the response curves are stored in a global file.
 And if those are accessible from Edith?
 And no, they're not.
 We did not need to tune the response curves hardly once.
 Maybe two or three times we had to tune those.
 So we just left them in the global files,
 read when the game was initialized.
 And second question was, did we use these graphs
 that we're looking at here during the tuning of the game?
 And no, we didn't.
 We just used our imaginations.
 So actually, we still have five minutes, right?
 We have another group coming in.
 Right at 6.30.
 Right at 6.30.
 OK, one more question.
 White shirt.
 Are these global models adapted to user input?
 Or is that a response curve?
 Are the response curves, are they adapted to user input?
 Yeah.
 Is the player allowed to get to a position
 where he can follow the adaptive mode of response?
 So he's asking if the mode of response curves
 are adaptive to the user's input.
 And no, they're not.
 They're always the same.
 Do you consider making them adaptive?
 Actually, he's asking if we ever considered
 making them adaptive.
 And we never considered making it
 adaptive to user interaction.
 But actually, there are hooks that exist
 to make those person-specific.
 So each person can have a different level
 of intelligence.
 However, they all use the same level in the final version.
 And I wish I had more time for questions.
 So maybe if anyone has anything to ask me afterwards,
 that'll be fine.
 And that's it.
 Thank you.
